Looks like there are failing tests. You can use [@]macroexpand to see what the new @inferred definition generates.

Hello @aviatesk , thank you for the suggestion.

I looked up some of the failing tests. One expression that caused the CI tests to fail is for example this one. I tried reproducing the same behavior with the following.

julia> using Test

julia> A = [1]
1-element Vector{Int64}:
 1

julia> @test @inferred push!(A,2) == [1,2]
Test Passed

julia> A
3-element Vector{Int64}:
 1
 2
 2

It seems that my modified _inferred gets as input the entire expression push!(A,2) == [1,2], and evaluates the mutating part of this expression twice, once to get the result and once when the raw expression is passed onto gen_call_with_extracted_types.

As far as I understand, the original _inferred alleviates this by first converting the input expression into a :call expression and then isolating and evaluating the arguments. It then rebuilds a function call with these already evaluated arguments.

I tried doing the same but by extracting and evaluating the arguments of the raw expression but this proves difficult, for example for function call with keyword arguments or for do-blocks :

julia> :(map([1,2]) do x 2x end).args
2-element Vector{Any}:
 :(map([1, 2]))
 :((x,)->begin
          #= REPL[11]:1 =#
          2x
      end)

whose first argument is map([1, 2]) and can't be evaluated.

Do you think I'm heading in the right direction or did I oversimplify the code too much ?

Another option would be to add a do-block transformation at the beginning of the function like with :ref expressions, but the code would be similar to what's already in gen_call_with_extracted_types.

(PS : sorry for the delay in my reply, as I'm on and off due to summer holidays.)